Support NumPy 2.x 64bit integers on Windows - #551

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 27.44%. Comparing base (9bcbb71) to head (c6930bf).

@@           Coverage Diff           @@
##           master     #551   +/-   ##
=======================================
  Coverage   27.44%   27.44%           
=======================================
  Files         152      152           
  Lines       28151    28151           
  Branches     8419     8419           
=======================================
  Hits         7725     7725           
  Misses      17958    17958           
  Partials     2468     2468           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

@amontoison should we be worried about the failing Poison tests?

Nope, it is like expo, we may have a flaky test for slblt.

The failure is in slblt_factor.F90:2350, which is

        !$omp task firstprivate(p, pp) private(nok, naok) default(shared) &
        !$omp      depend(inout: sync(p)) depend(in: sync(pp))

Thus just another case of omp not tidying up after itself, I believe; this is a know issue with omp that makes speculative mallocs.

Thanks both, in that case are we happy to merge this and make a new bugfix release of GALAHAD?

It is fine for me @jfowkes.
We just added SLBLT since 5.5.1 but I am fine to do a new release.

Thanks @amontoison, it is more for the Python wheels than anything else.

OK for me, too. I won't be able to sort out the expo issues, although I suspect it is simply that the expo C tests are using the default sparse solver, and not one we know works. Normally we have something like

strcpy(control.trb_control.trs_control.symmetric_linear_solver,"sytr ");

blah, blah, blah to set subproblem linear solvers, but I don't think we do in expo C tests. We will need the C equivalent of

control%SSLS_control%symmetric_linear_solver = symmetric_linear_solver
control%TRU_control%TRS_control%definite_linear_solver                      &
     = definite_linear_solver
control%TRU_control%TRS_control%symmetric_linear_solver                     &
     = symmetric_linear_solver

where

CHARACTER ( len = 5 ) :: symmetric_linear_solver = 'sytr '
CHARACTER ( len = 5 ) :: definite_linear_solver = 'potr '

You might try that (both in expo/C/expot.c and expotf.c)

Thanks both, in that case I propose a v5.5.2 release to fixup and update the Python wheels and add SBLT.

I don't think the flaky expo test should hold this up as the problem seems to be with the test setup and this should be very easy to fix (I would do this in time for the release but unfortunately I am away at a workshop all next week).

@jfowkes The PyPI compilation failed for the release 5.5.2:
https://github.com/ralna/GALAHAD/actions/runs/34624008343/job/103453465709